COMPUTER PROGRAM PRODUCT FOR PERFORMING TESTING OF A 
SIMULATED STORAGE DEVICE WITHIN A TESTING SIMULATION 

ENVIRONMENT 

CROSS-REFERENCE TO CO-RELATED APPLICATION 

[0001] The present invention is related to the subject matter of the following commonly 

assigned, co-pending United States Patent Application: Serial No. 10/ , (Docket No. 

HSJ920030143US1) entitled "Method for Performing Testing of a Simulated Storage Device 

Within a Testing Simulation Environment" and filed , 2003, which is incorporated 

herein by reference. 

BACKGROUND OF THE INVENTION 

1. Technical Field 

[0002] The present invention relates in general to an improved computer program product for 
testing and verification, and, in particular, to an improved computer program product for testing 
and verification in a simulated-hardware environment. Still more particularly, the present 
invention relates to an improved computer program product for performing testing of a simulated 
direct access storage device within a simulation environment. 

2. Description of the Related Art 

[0003] The modern trend toward constant and rapid improvement in technology has forced 
technology companies to adapt to a market environment where the saleable life of a technology 
is limited and frequently prematurely terminated by the frenetic pace of innovation. In order to 
maximize the useful life of a product when facing a shrinking window of time between 
commercialization of an invention and displacement by superior innovations, technology 
companies have undertaken every possible effort to reduce product cycle time. Manufacturers 
frequently turn to virtual prototyping and simulation testing techniques to enable them to test 
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products before the design reaches the factory floor. Virtual prototyping and simulation testing 
techniques carry the added benefit of reducing the cost of development. But as will be discussed 
below, current virtual prototyping and simulation testing techniques also add risk and costs to the 
design process. 

[0004] Simulation testing techniques inject unique complications into the design and testing of 
complex technological products. A recurring and somewhat daunting problem relates to the need 
to test the interaction of separate systems, both of which are in development at the same time, to 
external stimuli. Where separate systems such as underlying hardware and control software form 
integral parts of the product delivered to the customer, integration testing must be used to verify 
that the parts will, in fact, perform together as specified. Particularly in modern data processing 
and storage systems, where the hardware and software form equally critical parts of the product, 
it is necessary to rigorously test their interactions. 

[0005] Testing the interaction of the hardware-under-development with the software-under- 
development sounds inherently simple; one need only produce a prototype of the hardware and 
then monitor the performance of the control software on the completed hardware platform. The 
unfortunate reality is that time-sensitive cycles of parallel development often require integration 
testing of the software and the underlying hardware prior to production of the hardware itself. 
Testing must frequently occur before a working prototype of the hardware exists. 

[0006] In the direct access storage device industry, as in many others, the answer has been to 
produce a virtual prototype of the relevant hardware. The virtual prototype is a data processing 
system program, operating in a testing simulation environment, which models the expected 
behavior of the hardware. In order to perform integration testing, a specially engineered version 
of the software under development is conventionally loaded into the simulation environment and 
sends commands to the virtual hardware. Such methods have allowed for testing of the expected 
interactions of non-existent hardware with the software designed to control the virtual hardware, 
but the use of a specially engineered version of the software carries its own problems. 
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[0007] Current testing methods call for the insertion of special program instructions into the 
software, which will presumably be removed from the software at a later time. As an example, a 
testing and verification group might need to determine the combined response of the software 
and the hardware to the presence of a thermal abnormality in the underlying hardware. To do 
this, lines of code in the software will be inserted, which will, in effect, write a thermal error 
code to the underlying hardware. The hardware will then react to this error code, taking some 
measures based on its own firmware, and passing the error back to the software for further 
scrutiny. 

[0008] The first, and most obvious problem with this approach, is that integration of the special 
error-code instructions into the software-under-development changes the performance dynamics 
of the software. Machine cycle times are skewed by the need to perform the lines of code that 
pass error codes to the hardware. This reduces the accuracy of the simulation by causing the 
development and testing version of the software to exhibit behavior that will not be present in the 
production version of the software. Because the timing of microprocessor operations can prove 
critical to successful operation of the completed system, this mere problem of timing due to 
presence of testing instructions can severely cripple the usefulness of the integration testing. 
Injecting work-arounds to correct for delays in software operation can introduce an added factor 
of unreliability. Simply put, the fidelity of the test to the software that will actually form a 
component of the finished product is substantially undermined. 

[0009] Another problem relates to the burdensome nature of manual insertion of the testing 
commands into the software-under-development. The manpower involved in properly coding 
the test instructions into the software-under-development adds cost to the development process 
and creates version management issues. Frequently, a separate testing and verification group, 
composed of persons less familiar with the software-under-development than the people who 
have written the software, performs the integration testing. The cost of providing the testing and 
verification team with the requisite familiarity with the underlying software, and then having 
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them perform, and later remove, changes to the software, adds materially to the cost and number 
of skilled programmers necessary to deliver the product. The fact that the changes to the 
software necessary to facilitate testing must be made manually also discourages thoroughness in 
testing by imposing an unacceptably high time-cost for each test performed. 

[0010] Finally, the presence of human error in the process of testing creates real problems. One 
such problem is the problem of version management. Once simulation testing has begun, the 
programmers, who are developing the software, must take care not to make revisions to the 
software without insuring that the revisions are passed to the testing and verification group. 
Frequently, in order for the testing and verification group to make the modifications that need to 
be made in order to test the software, they must isolate the code from further tinkering by the 
software design team. The frequently unhappy result is that revisions to the software are lost 
because the revisions are not inserted into the most current version-under-test, or that they are 
inserted and are never tested because the testing and verification group had no notice of the 
insertion of the code. Occasionally, testing and verification instructions are inadvertently left in 
the software product after testing is completed, causing the finished product to display 
anomalous behavior that was not anticipated by the designers. 

[0011] All of the above-mentioned problems undermine the effectiveness of current testing 
techniques, and a remedy that would both lower the cost and increase the effectiveness of 
simulation testing is desired. What is needed is a separation of the testing function from the 
development of software through a computer program product for simulation testing that 
automates the error code process and removes the need to insert testing instructions into the 
software-under-development. 
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SUMMARY OF THE INVENTION 

[0012] A computer program product for performing testing of a simulated direct access storage 
device in a testing simulation environment is disclosed. The computer program product provides 
a software representation of a group of hardware components within a simulated direct access 
storage device. The computer program product also uses a control program module within the 
testing simulation environment, wherein the control program module interacts with the software 
representation of the hardware components, and a testing program for interacting with the control 
program module and the software representation of the plurality of hardware components. In 
response to detection of an occurrence of a pre-selected event within the simulated direct access 
storage device, one or more codes are sent from the testing program to the software 
representation of the hardware components and the correctness of a response by the control 
program module to the one or more codes is determined. 

[0013] All objects, features, and advantages of the present invention will become apparent in the 
following detailed written description. 
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BRIEF DESCRIPTION OF THE DRAWINGS 
[0014J The nove, features beheved characteristic of the invention are se, forth in the appended 

I™' TV 6 inven,i °"' " we " " a prefe,Ted mode of wi " ** - <— — < »y 

reference to the fohowing detaiied description of an i„nstrarive embodiment when read i 
conjunctton with the accompanying drawings, wherein: 

[^ Figure , is . block diagram o[ a ^ ^ ^ ^ 

env ' ronmen, in accordance w,th a emb ° dtae " t ° f p-», 
ir rr H - is a wock diagram ° f a tes,ing scnpt ffle data — • <• — « a 

preferred embodiment of the present invention; 

ICOn, Fignre 3 is a flowchart of a process for perfotming tes, events in a behavior-shnniation 
envtronment, ,„ accordance with a prefe„-ed embodtmen, of the present invention; and 

10018, Figure 4 is a btodc diagmm i„ ustanng message flow ^ ^ ^ 
Ptocesstng system for the process rf perfoming ^ ^ fa a 

envtronment, ,„ accordance with a preferred embodiment of the present invention 
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DETAILED DESCIUPTION OF THE INVENTION 
[00I9J With reference „ ow , 0 ae 

Pressing system equipped °* •* reference ,„ Figure . ^ 

- — « c: ~: pro ^ in 

expla„a t io„ >m a„ ycomponentso " US,rated F »r P»1»se of simplicity in 

only -hose pares necessary «„ f a c„C 7 ' ""^ *» F ' G - - 

-ponents of a data ^J^I^T ^ ""^ ^ ^ ***<■ 

- — ■» * dala pro j rcr^r/r - f,g - 1 - • 
=zz ,atw be ~~ - -~ -= g r:r::: 

** "rtve or other direct access sto^e d 3 IM "* « * 

108 connects t „ „ ne or more ^ of _ ^ « a ~ k cabie II, I/O 

monnor, and printer through the use of , ° r m0re ° f a ^"l. 

linkage, ~ ° f — -ch as oabies or wiretes 

[0021] Processor 104 exen.tPc ~™ 

operating systen, „ 7 ~ ~ — °'~g - present nation. An 

» oontro, 10, -tCni * ~ 

~ 104 _ a Jahon ^ ^ * ^ J - — 
Program 118 calls for the execution nf • , ■ S,mulat IO n environment 

g program 124, and a control program module 128. 

[0022] Within RAM 102 A»t» 

— ■ * o^ingTu ZZT^ ^ ^ " ~ ~ 
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~ g :rr:zi:' qu, r y rea,,2e aat — ■ — — 

* -ope of the present 10 ° r S ~ f " *>- *>» without depart ,, g from 



100231 Simulation environment pr „ 

«« « - — o„ P ii , 8 :r; r ::r r program -** ~ - 

Nation testing. Genera „ v ,„ . . . ' "'^ Pr ° Vldes a «"« of tools for behavior . 

hardware and Sim t,ll ' ™— *- »f 

oimuiation environment program ITS ■»» +u 
to "» ~„s, in conjunctio „ wi , h one or P mo ™ ™ "» «* ~» ofnt.es contained 
124, and contro, program moduIe M , o ™" "-*»• "ode, ,20, testing program 

program moduie ,28 (0 extema , „ . T*" * ~ ° f hard ™- ™>de, no and con.ro, 

— * co^:::::rr: s ::r m ^ - -* * - 

direct access storage device control e " * * * ^"tation of 

a new centre, program module ,28 is under tests, snch as those where 

looped hardware, hardware mo de, 2 m aPPliCa,i °" * 

— ,„ other tesB , ^ ^ ^ ~» • ™de, of pree,o Usly depioved 

developed with no e xistl „g hardware> ted J^™7 ~ ^ - being 

systenrefhardwaredrathasnotyetheenprodL " ' * ° f *" "*» 

mode, ,20 and control P rogra m m odu,e ,28 ,o ex J a 7 °° " ^ 

ser. pt ffle data stractoe ^ ^ *» - - — s,im„„ container, in testing 
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through the use of connecting means 11/; u 

°< o f , mulation MViro Lr~ ; ;;: ,es * — * al , 

even, scrip, ffl. ^ ^ * ■««-» «< operating system m 

[0026] Turning now to Fieure 2 a <»«♦• 

» accede witb . prefe L «" <- — g test events> 

on** from FIG. 2, a „ d only those £ ^ «* «<* *. st^re 2.0 have 
"venbon have been i„ clu ded. All c„ raD0 „L 7 ° Und ««ng of the 

">« have been „ mitled from WG ' . ' * ' ""^ eVen ' ^ «» *>* structure 200 

wi,hou, departing from ^ f * "~ »y , ater be developed and 

da,a sbucbrre 200, ,abe,e d in the previous ' to " ^ — scrip, ffle 

wi» •XPically contain one or more ^ ' " S ' eS ""S even, scrip, ffle data stmcture , 22 

- « co mp „„e„, Testl „ g even , ™bTr ^ ' aWS reflK,i " g 

•—g even, da,, subsln , clure 3 200 may co„,ain as few as one 

subsbucrures. hyP0<he„ca„y „ mitless p|ura% rf ^ ^ ^ 

[»»») ,„ a p refemd embodiment present jn nQ 

snbsbnetores have been inc , uded . ^esetesbn. , ^ ' eS,i " g eveM 

oa,a 202 , a seCMd lesn ^'~ *« ace a first testing even , 

- :r - . fc Prefemd r~ rjr^T 3 -:^— 

substructure contains six fiefcfe. First , cstim , ' ^ 2 ' each '«mg even, daIa 

- « a chec k pom, even, ~ J ^ " — 3 — 

checkpoint even, , im e 0ut ^ fle|d '. CheCk P°'"< «« q-li&r Oata field 212, . 

'" " tes " n « "en, dala subaruenrre 206 
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have been left blank. The data fi^Mc • 

™ed w ith hyp01he , ical va , ues ™ event data substrac(ure 2M haye 

a pa« o f „» testing event data s(rac :;;tr sw " 8h an examp,e ° f 



f0028J Component data field 208 1 

■eve,, simulation environmen( 1M w,„ operate . ^ , machme ^ 

of hardware mode, 120 t „ ascertain the memo' ^ *" ^ 208 Wi * «* aid 

^ action by componeM da(a fidd ^ ^ * ^iated memory « desigMted 

^ in componem data field 208, are then s72Z <*« 
*-re 202. „ second te , g ^ » * * * *, ,esfi„ g even, data 

'"<hca.es to. me simulated hardware subsystem on vTT C ° mP ° nen ' d, " a **' 220 

10029] Checkpoint event data field 210 describes * 

hefore pe rfonnmg actio „ ^ ^ " ~* «■ which te s«„ g program m M , 

event dan, substntcmre 204 oh ^ 7 ^^"^ ** s„ bstnjc mre 202. ,„ second 
which ,es„„ g program IM w „, 2~ *■ Md 222 -hat me even,, for 

data Centre 2.4, is a sector read **" '» ««• even, 

WO) Checkpoin, even, oualifier data fieid 212 d „ 

bribed in checkpoin[ nm ^ * 12 addifiona, de M s of the eve „, 

checkpoint even, qua ,ifi er ^ fie , d 2U ^J™^ *«« *<■ subs.mcfi.re 2.4, 
wii. wait before pe rf „ mi „ g aclio „ describ J ^ * P^m ,24 

— read rem rai „ g . value tba , ^ fc — «** -bsfipemre 204, is . 

[0031] Checkpoint event timeout data fi^M J 

>« WU! wai, for the Kcma -~e ,e„ gtb oftfale that 

second testing event da(a ■ checkpoint even, data field 210. „ 

204, checkpom, even, ,i me o ut data fleld „ ^ ^ 
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in second testing event data substructure 204 to fail. 

[0032] Error injection/action event data field a u , 

will perform after «he occurrence JT I *" "** 

acnea the end of testing event script file data structure 200 Tn a ■ 
substructure 204, ,ast entry data field 218 indicates ! ' § ** 

204 is not the end of ~- ^ « data ^structure 

the end of testing event script file data structure 200. However in n* re f 
data substructure 206, where component data field 232 h , § 

checkpoint event qualifier data field 236 h / ^ *" 234 ' 

4 data tield 236, checkpoint event timeout data field a 

—action even, data M 2<0, have bee „ , eft ^ for ^ 
explanation, las, enfry data field 242 is se, to ,he value of one , " * " 

■he valne of one ,o i„diea,e ,o ^ ^ f,eld 242 is s « "> 

-p,fi,e d a,a S , ro ::::: gprosram 124 * has - - «~* - 

leneth of rim. v f ^ teStmg P ro S ram ™ waits for the 

departing from the scope of^^presenHnveofio^ ^ ^ ^tbstituted for those shown without 
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[0036] With reference now to Figure 3 a hiah i™»t a u 

event, in u • high-level flowchart of a process for performing test 

;r i;::;rr; env — ■ - — - • — — - - 



ZIZt: t a, ; ,ep 3o °- which dep,c,s * 

program „ 8 , m accordance rt , he preferred 

r e ~ — »« co mP „ a e„ ( jit t: 

snrattaron envrronmen, program 118 from storage ,06 ,„ ram 102 a „, , 

instructions on processor 104. RAM 102 and executtng ,niti a l 



[00381 The process then proceeds ,„ step 302, which „, ustrales the „ m 

~ ,nve„„o» loadmg a hardware mode , m ^ ^ ~ 

: cZir :~ s such as — - - — — . 

other tests, snch as those where an entirely new hardware platform is being developed with no 

::;rr *— - - - - - — - -« •« r: 

event script file data structure 200. w»ung 

[0040] The process then moves tn «t™ 111 1 • » . . 

P ' Whlch de P Jcts the te sting program 124 reau^rinc 
testing event data substructure im w *u . . i""g"m 1^4 requesting 

substructure 202 from the testing event script file data structure 122 stored in 
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detent whether ,he condiiion described in che kp Te J , ^ 7 " 

checkpoin. even, qualifier 212 If*, , ,• ° CCU,TCd 35 described in 

checkpoint even, 22. I I T* ^ ** * "»**» - 

procei the „ ™ : described ,n checkpoint ™ *— - 

and fte procras ^ I f ST " T ^ 3 ^ " 
wh„e the simtdation environmeT m7 s , , T ^ ** $Ub ~ ^ 

vartable LBA#, (he process moves to step 316 as described below. 

[0042] If the testing prog™ determines ^ 

has occurred as described i„ Chechen, even, qualifier 2, ^1 

depi Cts sending . code set to simu szz* t r d moves to s,ep 3i6, 

substructure 204 while the =i , .• d teS " ng event 

™de, 22. mel" °" * «* <*-— hardware 

-ponseofthes^toa^l; ' ^ " *— * *« - 

[0043] The process then proceeds to sten lis „ u- u a ■ 

-ponding to the thermal ^ ^ "* ^ ~ ^ '» 

- Ptogra. quer^ J J^^Z * - * h 
hardware mode, ,20 to the even, in step 3,6 s„ , ""^ * 28 

- - — - - fa zrz'rzirrrr 

commands ,„ m„„ itor mi record ^ .„ ^ ~ »«• wh.ch mc.udes 
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[0044] The process then moves to sten W nhi u n 

— the end „ f Ksling event J p( ^ , ^ «- « - » has 

file data structure 200 In sec onH „ ,• " " S ttS,i "« event SCTi P' 

ue 01 one - Th at last entry data field 242 i« «* 
structure 200. ° f testin S eve "t script file data 

»^.^rc"»~r ,,,,,H,,i, * - * ,,, --~ 

us results. This step includes storing nrocess 1™ m ■ 
and ma y mclude deliveiy of a perfomance ^ (o _ ~ a,„ rag e IW 

*e process moves t0 step 32<> ^ 1 T 

preferred embodiment of the present invention . ^ ' e " d '" g " r0Cess ° f *• 

[0»4«I If, in step 323, testing p rogram m does 

l«ting event script data structure 122 ,h, ,h ^ ' he ha 

-ins prog™ M " t; r0CeSS "*< ~ * -P 3", which depicts 

*****»»m JZZ£Z dataS "~ 2 » 2 -ven, scrip, 

[0047, Turning now t0 Fis „ rc 4> , ^ 

data processing system for the . g "° W between the eomponents of a 

environment, in accor(bnce with ~ "t™ 8 ~ '» • ^vi„ r simulation 

The message now mag™ J^^T "r ^ " dePiC,e<l 
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[0048] The test event begins with step 312 of FIG. 3, which depicts the testing program 124 
requesting testing event data substructure 202 from the testing event script file data structure 122 
stored in RAM 102. This is typically accomplished when processor 104 sends a 'what is next 
event' query 400 to RAM 102. 

[0049] The process depicted in FIG. 3 then proceeds to step 314, which depicts the testing 
program 124 receiving testing event data substructure 202. This is accomplished when RAM 
102 sends 'next event is' instruction 402 to testing program 124 on processor 104 from testing 
event script file data structure 122 on RAM 102. For purposes of this discussion, the invention 
will be further described on the assumption that second testing event data substructure 204, 
described with respect to FIG 2., was sent by RAM 102 as 'next event is' instruction 402 to 
testing program 124 on processor 104. Analyzing second testing event data substructure 204, 
processor 104 will use instructions contained in testing program 124 and simulation environment 
118 to determine that component data field 220 indicates that the simulated hardware subsystem, 
on which the action described in second testing event data substructure 204 operates, is the disk 
interface subsystem. 

[0050] The process depicted in FIG. 3 next moves to step 322, which depicts testing program 
124 determining whether the pre-condition to the testing event is satisfied. This is accomplished 
by testing program 124 sending a 'checkpoint status' query 404 to simulated memory 126 
through the messaging capabilities of the testing simulation environment 118. Here, the 
'checkpoint status' query 404 will request the latest sector read as in second event data testing 
structure 204. Simulated memory will reply to the 'checkpoint status' query 404 with a 
'checkpoint value' message 406. For purposes of explanation, we will assume that the 
'checkpoint value' message 406 returns the value 'LBA#' specified in checkpoint event qualifier 
224. 

[0051] Having satisfied the checkpoint condition required in step 322, the process depicted in 
FIG. 3 would next progress to step 316, which depicts sending a code set to simulated memory 
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126. In second testing event data substructure 204, then, while the simulation environment 
program 118 is simulating the operation of the hardware model 120, the testing program would 
write to simulated memory 126 a code set simulating the detection of a thermal asperity. This is 
accomplished by the testing program 124 sending an 'error code value' message 408 to the 
simulated memory 126 by writing the value of an error code to simulated memory 126. Though 
the exemplary 'error code value' message 408 illustrated in FIG. 4 contains only an error code, 
it could also contain debugging instructions in addition to the error code. 

[0052] The process depicted in FIG. 3 then proceeds to step 318, which depicts the control 
program module 128 and hardware model 120 responding to the thermal asperity code. This is 
accomplished as simulated memory 126 sends 'request instruction' 410 message to control 
program module 128 and receives an 'instructions' reply 412. Hardware model 120 carries out 
the instructions contained in 'instructions' reply 412. Simulation environment program 118 will 
track the cycle times of interaction between control program module 128 and hardware model 
120 to achieve a real-time processing of the error code response and will suspend tracking the 
'clock time' of control program module 128 and hardware model 120 while performing 
operations that reside in the testing program 124 or simulation environment program 118. 

[0053] The process described in FIG. 3 next moves to step 320, which illustrates the testing 
program querying and recording the response of the simulated hardware to the code set in step 
316. Such recording is performed through the use of command lines in testing event script file 
data structure 122, which includes commands to monitor and record variables in the simulation. 
Querying and recording are accomplished in FIG. 4 as testing program 124 sends a 'provide 
response' query 414, which will typically read the value of a register in simulated memory 126 
and simulated memory responds with a 'response answer' message 416, which will typically 
contain the value of a register in simulated memory 126. Testing program 124 will typically 
then process the result obtained in response answer message 416 and report the result to process 
log 123 in RAM 102 by sending a 'store report' message 418 to process log 123 in RAM 102. 
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[0054] The process described in FIG. 3 then moves to step 323, which illustrates the testing 
program 124 checking last entry data field 218, which represents a flag set to inform testing 
program 124 that it has reached the end of testing event script file data structure 200. In second 
testing event data substructure 204, last entry data field 218 indicates that second testing event 
data substructure 204 is not the end of testing event script file data structure 200. However, in 
n ,h testing event data substructure 206, last entry data field 242 is set to the value of one. That 
last entry data field 242 is set to the value of one to indicate to testing program 124 that it has 
reached the end of testing script file data structure 124. 

[0055] If testing program 124 discovers that it has reached the last entry in testing event script 
file data structure 122, as portrayed in FIG. 4, then the process next proceeds to step 324, which 
depicts testing program 118 publishing a record of its results. This step will typically include 
storing process log 123 in storage 106 by sending a 'store process log' message 422 to storage 
106 and may include delivery of a performance report to user I/O 114. In FIG. 4, delivery of a 
performance report to user I/O 114 is accomplished as testing program 124 sends a performance 
report message 420 to I/O control 108. This performance report message causes I/O control 108 
to display a performance report on user I/O 114. Once step 324 is completed, the process moves 
to step 326, which illustrates testing program 124 ending the process of the preferred 
embodiment of the present invention. 

[0056] If, in step 322, testing program 124 does not conclude that it has reached the last entry in 
testing event script file data structure 122, then the process next proceeds to step 312, which 
depicts the testing program 124 requesting the next testing event data substructure 202 from the 
testing event script file data structure 122 stored in RAM 102. This step involves a repetition of 
many of the processes demonstrated in FIG. 4. 

[0057] While the invention has been particularly shown as described with reference to a 
preferred embodiment, it will be understood by those skilled in the art that various changes in 
form and detail may be made therein without departing from the spirit and scope of the 
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invention. It is also important to note that although the present invention has been described in 
the context of a fully functional computer system, those skilled in the art will appreciate that the 
mechanisms of the present invention are capable of being distributed as a program product in a 
variety of forms, and that the present invention applies equally regardless of the particular type 
of signal bearing media utilized to actually carry out the distribution. Examples of signal bearing 
media include, without limitation, recordable type media such as floppy disks or CD ROMs and 
transmission type media such as analog or digital communications links. 
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